1. Technical Field
The present teaching relates to method and system for data connections. More specifically, the present teaching relates to method and system for connection pooling mechanism.
2. Discussion of Technical Background
Computer applications have evolved over several decades. Modern computer applications often manifest themselves in an infrastructure that involves layers of support. In addition, due to diversity of platforms on which a computer application user can operate, more and more computer applications are designed to support interfaces to facilitate the applications to interact with users of different platforms. For example, some users may interface with a computer application via an application designated window displayed on a desktop computer (e.g., PowerPoint) but other users may interact with the same underlying computer application via an Internet interface which allows multiple users across the Internet to share the same PowerPoint application. As another example, an account management system may allow an end user (customer) to interact with an Internet interface to change account information or check account balance information. The same account management system, however, may also allow a billing specialist from the service provider to conduct monthly billing activities. In this case, the billing specialist may interface with the account management system differently. In addition, when different users interface with an application differently, the underlying communication protocols used may also differ. In an account management system example, some may use XML and some may use FTP.
To make a computer application, especially a network based application, perform its core functionalities, an application is often divided into a front end and a back end. Front end applications are those used to interface with different users. Back end applications are those used to perform certain core functionalities of the application. For instance, a front end application of an account management system may be devoted to interfacing with customers to allow a customer to change the account information, to change subscription, etc. However, a different front end application may provide the interface for billing specialists.
The interaction data from the front end application may need to be sent to the corresponding back end of the application where all the core functions are performed and data are stored in databases. For instance, a customer may request, via a front end interface of an account management system to change the cellular phone service subscription from a 200 free minute plan to a 400 free minute plan. Upon receiving the information regarding the change, the front end has to communicate with the back end to effectuate the change. To achieve that, the information received from the Internet from the customer needs to be delivered to the back end in a form that is recognizable by the back end. This is often achieved via so called middleware.
FIG. 1(a) (Prior Art) shows a conventional system configuration 100 between front end applications 110-1, 110-2, . . . , 110-K and a back end system 150 via a middleware called enterprise service bus (ESB) provider 130. As shown, the front end applications communicate with the ESB Provider 130 via a network connection 120. Upon receiving the information from a front end application, the ESB Provider 130 forwards the information to the back end system 150. In some situations, when the front end and back end system support different communication protocols, the ESB Provider 130 may also translate information from either side by transforming from the source format to a destination format to facilitate communication. In some systems, specific buffers may be deployed to store messages from either side. For example, as shown in FIG. 1(a), message queues 140 may be used to buffer messages from front end applications and back end systems. A request made by a front end application may be converted into a message of an appropriate format and stored in the message queues 140. Such queued messages may then be retrieved by the back end system 150 and processed accordingly. When the processing is completed, the back end system 150 may also send a response to the message queues 140. Such buffered responses may then be retrieved by the ESB Provider 130. Such retrieved responses may then be transformed into a format appropriate to the front end application and transmitted to the front end application.
There are other functionalities performed by the middleware ESB Provider 130. For instance, for each transaction that a front end application requests the back end system 150 to perform, certain transaction information (e.g., account identification, nature of the transaction, status of the transaction, date and time of the transaction, etc.) may be recorded in some database(s) within the ESB Provider 130 to facilitate future needs. For instance, a bank account management system may allow a customer to deposit or transfer money around. Information related to all such transactions may be stored in the ESB Provider 130. Another application may be designed to generate monthly statements. To do so, the monthly statement application may retrieve all the information stored in the ESB Provider 130 related to all the deposits and money transfers made by each customer. In this case, the monthly statement application may retrieve transactional information from the ESB Provider.
To access information stored in a database, a database connection is usually made to the database driver. To open such a connection is usually time consuming. In addition, when a data access operation is completed, the database connection is usually closed, which also takes time. When such access is frequent, the time required to open and close database connections negatively affects the bandwidth needed to access the databases. To solve this problem, connection pooling has been used. Under connection pooling, a pool of database connections is created in which a set of database connections are open and can be provided upon request. Once a connection is used, it can be returned to the pool so that it can be used for the next request. That is, the database connections in the pool are open all the time so that the time required to open and close database connections is saved.
FIG. 1(b) (Prior Art) shows a conventional connection pooling scheme under which the number of connections opened in the connection pool is determined by each thread group during execution. As shown, at the front end application layer 160, there are, e.g., three thread groups, 170-1, 170-2, and 170-3, and each thread group includes a number of application threads (3, 5, and 4, respectively). In this conventional solution, each thread group determines its own number of connections pooled. For instance, the first thread group 170-1 opens 3 connections for pooling purposes. The second thread group 170-2 opens 5 connections for pooling purposes. The third thread group 170-03 opens 4 connections for pooling. Overall, there are a total of 12 connections open and connected to the database driver 180 and the database 190.
With this conventional solution, the total number of connections opened for pooling equals the number of application threads and, hence, there is no actual pooling. Because the number of connections opened is large, it is therefore still costly. This connection pooling solution does not provide much advantage. A more cost effective connection pooling scheme, for example, in the context of ESB Provider, is therefore needed.